home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19990422-19990725
/
000102_news@watsun.cc.columbia.edu _Wed May 26 16:52:54 1999.msg
< prev
next >
Wrap
Internet Message Format
|
1999-07-23
|
2KB
Return-Path: <news@watsun.cc.columbia.edu>
Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id QAA12523
for <kermit.misc@watsun.cc.columbia.edu>; Wed, 26 May 1999 16:52:54 -0400 (EDT)
Received: (from news@localhost)
by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id QAA28263
for kermit.misc@watsun.cc.columbia.edu; Wed, 26 May 1999 16:33:56 -0400 (EDT)
X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
From: jrd@cc.usu.edu (Joe Doupnik)
Subject: Re: kermit process hangs around after terminal disconnect
Message-ID: <Ii1+RNVS17yW@cc.usu.edu>
Date: 26 May 99 12:01:58 MDT
Organization: Utah State University
To: kermit.misc@watsun.cc.columbia.edu
In article <7ih212$rvs$1@nnrp1.deja.com>, Mr. Scott <scott_davis@my-dejanews.com> writes:
> Thank you for responding.
> Yes, it pretty much is a Procomm->UNIX issue because the shell is
> hanging around. I'm just incredulous that UNIX doesn't swiftly detect
> the broken connection; instead, waiting hours, days, or sometimes what
> seems like forever to finally realize that no-one is on the other end
> of a telnet connection. What's up with that? Can you explain why such
> dumbness would happen? I program sockets a bit, and it was my
> understanding that "send", "recv", or whatever returns a zero to
> indicate EOF when a TCP connection is broken. All the server programs
> I have written detect this condition immediately as the client shuts
> down, dies, terminates, whatever. Why doesn't the UNIX telnet/pty
> server program do the same?
-------
You've answered your own question. If there is nothing to say
on the wire then with TCP/IP nothing is said, and that is by careful
design. To sense a broken connection both sides have to say something
and then look at the function status returns.
One can pull the 10BaseT wire from an interconnection, go away
for eons, put it back, and neither end knows this has occurred. Replace
pulling wire with major nuclear event. Some systems provide a TCP/IP
keep-alive probe, but it starts very late and is very patient. See your
systems manager about details.
In the end the problem is not Kermit but the rest of the environment.
Joe D.